fix(axios-retry): call onRetry after delay completes instead of before #307
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…eRetry Changed handleRetry logic so that onRetry callback is no longer called immediately before the delay starts. Instead, it now runs inside the setTimeout after the configured retry delay has elapsed, and just before the retry request is sent. This ensures better separation between "waiting" and "sending" phases of retry, allowing consumers to handle cancellation or status updates accurately. Also removed the initial onRetry invocation that happened before delay.
|
Hi @mansourebadian, thanks a lot for looking into this. |
|
Thanks for the feedback. I’ll review and fix the tests to ensure they all pass, and make sure that all commits have verified signatures |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
In the current version, the onRetry callback is executed immediately after the error occurs — before the configured retryDelay has finished.
This causes onRetry to report retry information while the next attempt hasn’t actually been sent yet.
As a result, developers cannot accurately control or log the exact “just before resend” moment, and certain cancellation logic or tests behave unexpectedly.
Solution
The handleRetry function has been updated so that:
onRetry(currentState.retryCount, error, config) is moved inside the setTimeout callback.
The premature execution before the delay is removed.
Timeout variable naming and abort listener handling are made more consistent.
With this change, onRetry is now triggered right after the delay finishes and just before sending the retry request, making the retry flow more predictable and semantically correct.
Benefits
Better alignment between “waiting” and “resending” phases.
Accurate logging, metrics tracking, and UI updates for retry events.
Fixes unintended behavior in unit tests related to onRetry.
Related discussion: issue